NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/9915

Internet Message Format | 1996-08-05 | 7.0 KB

Path: goanna.cs.rmit.EDU.AU!not-for-mail
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
Subject: Re: Hungarian notation - whoops!
Date: 5 Mar 1996 14:39:13 +1100
Organization: Comp Sci, RMIT, Melbourne, Australia
Message-ID: <4hgd11$[e-mail]>
References: <[e-mail]> <4g9255$[e-mail]> <[e-mail]> <4h6hlo$[e-mail]> <[e-mail]>
NNTP-Posting-Host: goanna.cs.rmit.edu.au
X-Newsreader: NN version 6.5.0 #0 (NOV)

[e-mail] (Kazimir Kylheku) writes:
> >One legal input is one LEGAL input.

>Whether or not it is a legal input is implementation defined.

>What is the _guaranteed_ lowest signed integer, LONG_MIN?

>From K&R2, page 257:

>    LONG_MIN    -2143483647    minimum value of long

>This is clearly not the most negative two's complement 32-bit integer.

>By feeding -214348364_8_ to the abs() function or the unary - operator, you are
>exceeding the stated limit. Thus your code is not strictly compliant with the
>standard.

As you so rightly say, LONG_MIN is implementation defined.  The standard
*bounds* it, but does not *define* it.  I am aware of the C concept of
"strict conformance", and I am also aware that experts in comp.std.c have
found it remarkably difficult to construct one that is not trivial.  Code
that uses the implementation-defined value of LONG_MIN does not _violate_
the standard; it will not be strictly compliant but that doesn't mean it
isn't compliant.

>Look, two's complement gives you one extra negative number that you aren't
>supposed to use.  A sign/magnitude representation gives you two zeros instead.

The absolutely crucial point here is that TWO ZEROS ARE NOT A PROBLEM,
because BOTH of them act EXACTLY THE SAME for all arithmetic operations.

We have an exactly comparable situation with pointers.  A machine is allowed
to have any number of representations of "the" null pointer, and I've used
one where there were 2**31 representations of "null pointer".  That didn't
cause any complications in my source code, because they all behaved just the
way a null pointer is supposed to behave.

It is not the case that twos complement gives you a number that you are
not _supposed_ to use.  I have read the Pascal and C standards with some
care, and neither of the Pascal standards, nor the C standard, nor the
C++ draft standard, says anything about not being supposed to use -INT_MAX-1.

> >I am concerned about writing reliable maintainable software at affordable
> >cost.  I am only interested in hardware, languages, compilers, and so on

>Then don't expect variables to hold values outside of what is stated
>in the standard.

Oh ye infernal deities.  Can you not realise that my code does not rule the
world?  If I call an operating-system routine, I have to put up with whatever
it gives me back.  If my code is a library that can be called by other people,
it does not suffice for me to say "if you pass -INT_MAX-1 you have done
something stupid and don't blame _me_ if it doesn't work".  The point is that
other people's variables WILL hold values outside what is guaranteed in the
standard, and if my code breaks as a result >I< will be blamed.

Let's be absolutely clear about this:  the C standard guarantees only that
int can hold -32767..+32767, and the Ada standard guarantess only that
Integer can hold -32767..+32767.  If my code is run on a machine where the
implementation-defined range of int/Integer is -2147483648..2147483647
and my code crashes because someone passed in the value 1000000, I am NOT
going to get away with saying "well, you shouldn't expect variables to hold
values outside of what is stated in the standard", now will I?  Why should
any other implementation-defined-legal value be different?

>Ada is a fine language. C is a fine language. They exist because of creative
>individuals, who have different approaches to a similar problem.

No.  They have different approaches to DIFFERENT problems.
C was created for small team use on small systems for small machines.
Ada was created for large team use on large systems.

>Hiding the two's complement representation would require the generation of all
>kinds of extra code. It would be to the detriment of programs that never go
>near the ``largest negative value''.

That is precisely what I have against 2s complement.

>It doesn't have to be written with reference to what machine you are using.

I did not say that it did.  It can be written so that it will work on
any machine, and I showed how.  The point is that THE OBVIOUS METHOD DOESN'T
WORK IN TWOS COMPLEMENT!

> >    int like_atoi(char *p) {
> >        int sign = -1;
> >        int n = 0;
> >
> >        if (*p == '+') p++; else
> >        if (*p == '-') p++, sign = 1;
> >
> >        while (isdigit(*p)) n = n*10 - (*p++ - '0');
> >        return n*sign;
> >    }

>This program is poor, because it doesn't place restrictions on the input. If I
>feed it the string '123412341452345254623542435', it will produce a valid
>variable of type 'int', without signalling that an invalid value has been
>input.  Two's complement is the least of your problems here.

>By the way, ints can have the range as low -32767 to 32767, which further
>restricts the robustness of the code.

Oh COME *ON*.  Instead of answering the substantive point, which is that
there is an obvious way of coding this obviously simplified example,
but the obvious way DOES NOT WORK IN TWOS COMPLEMENT, you resort to dishonest
debating tricks. Can you not recognise a simplified example when you see one?

My actual code _does_ check ranges, and _is_ portable.

>If you write it properly, you could come up with a portable routine which works
>for decimal representations of integers in the range LONG_MIN and LONG_MAX, and
>signals an error condition for others. (I mean the *Standard's* minimum values
>for LONG_MIN and LONG_MAX, of course, not implementation-defined values derived
>from a local <limits.h>).

I have written it properly, elsewhere, and my code is portable, and does work
for all legal inputs.  The point I have to keep hammering home is that the
guts of the code, the statements that perform the actual calculations,
CANNOT USE THE OBVIOUS METHOD BECAUSE IT DOESN'T WORK IN TWOS COMPLEMENT.

>Is this your prime evidence that C is bad or do you have more?

In all this disucssion I have not once stated or implied that >>C<< is bad.
I have been complaining about TWOS COMPLEMENT ARITHMETIC, which is in no
way synonymous with C.

For another example of the peculiarities of twos complement arithmetic,
consider the fact that an arithmetic right shift on a ones complement or
sign and magnitude machine is always equivalent to division by a power
of 2, but not in a twos complement machine.  (I note that the C standard
does not guarantee that there will be an arithmetic right shift, so please
don't mistake this for a C criticism.)

--
The election is over, and Australia lost; the idjits elected _politicians_!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.